DEVELOPMENT

Can't touch the cross-chain bridges that crypto hackers love the most? An article explaining the classification and comparison of different cross-chain bridges: past, present, and future

share
Can

This article is authorized to be reprinted from NIC Lin, titled "Cross-Chain Bridge Comparison," written by XY Finance consultant.

This article will introduce what cross-chain bridges are, classify and compare them, and analyze some famous cross-chain bridge attack incidents.

What is a Cross-Chain Bridge

A cross-chain bridge is a bridge responsible for transferring "messages" between different chains. The type of messages being conveyed will be further elaborated. Examples of cross-chain bridges include Multichain, Celer, XY, Nomad, Rainbow Bridge, Hop, and more.

Chains are Unaware of Each Other's Existence

The common use case for cross-chain bridges involves transferring assets like ETH, BTC across chains. However, in reality, "assets" cannot cross chains because each chain operates independently and is unaware of the existence or state of others.

How does an ETH on Solana or BTC on ETH come about? These are minted by cross-chain bridges. As long as these bridges are secure, the minted coins are safe.

Note: For assets like USDT or USDC, some are minted by Tether and Circle on different chains, while others are minted by cross-chain bridges.

What Messages are Transferred?

While it may seem like assets are crossing chains, in reality, it's just "messages" that are being transferred across chains. These messages could be like "I locked/burned X assets on Chain A" or "I unlocked/minted Y assets on Chain B," and the recipient of the message will act accordingly based on the message content.

For example, when Alice wants to use a cross-chain bridge to transfer USDT from Chain A to Chain B, what actually happens is:

  • The cross-chain bridge's contract on Chain A transfers USDT from Alice and sends a message: "Alice locked 10 USDT with me"
  • The message is sent to the cross-chain bridge's contract on Chain B, which then transfers 10 USDT to Alice's address on Chain B
Asset cross-chain transfer is essentially a simple message relay, omitting many details in between

The core of a cross-chain bridge lies in the relay of "messages," and the most common cross-chain asset transfers we see today are just one of its many applications. Platforms like Aave V3 version operate as collateralized lending platforms running on multiple networks.

Limitations and Challenges

However, cross-chain bridges are not as simple as the example above. The fundamental limitation of a cross-chain bridge comes from the fact that "chains are unaware of each other's existence," thus requiring it to "trust someone to relay messages." Therefore, the primary challenge of cross-chain bridges lies in "how to verify the validity of a received message."

Note: The term "trust" in message relaying does not imply complete trust. It will be explained in the following sections that some bridges do not require trust in message relayers. Relayers may be good or bad actors, but there are certain assumptions about the characteristics of the relayers.

Security

The security of a cross-chain bridge essentially depends on:

  • How much trust is placed in the message relayers? Are there any assumptions about the behavior of the message relayers? Is it assumed that the message relayers can only honestly perform their tasks?
  • How to verify the validity of messages?

Next, we will explore the classification of different types of cross-chain bridges.

Classification of Cross-Chain Bridges

Cross-chain bridges can be broadly categorized into four types:

  • Trusted Relayers
  • Optimistic Verification
  • Light client + Trustless relayers
  • HTLC

(If you have other thoughts or opinions on the classification, feel free to leave a comment or discuss via email.)

1. Trusted Relayers

As the name suggests, Trusted Relayers are message relayers that are trusted. Essentially, once the message relayers are trusted, there is no need to further validate the messages. Any message brought by a trusted relayer is believed to be valid. With the assumption of trust in the message relayers and a centralized setup, the architecture is simplified, costs are lower, and user experience is enhanced.

There is nothing particularly special about the technology behind Trusted Relayers; it depends on the composition of these message relayers, which can be single or multiple (similar to multi-signature); each message relayer can operate using multi-signature or MPC.

It is important to note that the security assumption of Trusted Relayers is Honest Majority, meaning that the majority of message relayers must be honest individuals. If more than half of the message relayers are bad actors or compromised by hackers, the cross-chain bridge is no longer secure.

Additionally, Layer Zero also falls under Trusted Relayers, where the roles of message relayers are divided into "Oracle" and "Relayer" within their definition. However, this does not change the security of the entire bridge, which still relies on the assumption that neither the "Oracle" nor the "Relayer" roles are compromised. Compared to other Trusted Relayers bridges, Layer Zero's advantages include customizing security levels for each dApp. If high security is required, the number of "Oracle" and "Relayer" can be set high. Another advantage is that the security of each dApp is independent and not mutually affected.

Examples include: Multichain, Celer, LayerZero, Wormhole, Ronin Bridge, XY

2. Optimistic Verification

Similar to Optimistic Rollup, Optimistic Verification optimistically accepts relayed messages but verifies their validity. If found to be invalid, a challenge is initiated. The advantage lies in the fact that the system operates normally most of the time (as malicious actors are challenged and penalized). Since messages are valid most of the time, challenges are rare, resulting in low costs as there is no need to verify messages on-chain. However, there is a challenge period (Optimistic Window) that allows validators enough time to verify and initiate challenges. Taking Nomad as an example, the operation of Optimistic Verification will be explained.

Within Nomad, there are three roles: Updater, Relayer, and Watcher.

  • Updater stakes collateral and is responsible for guaranteeing message signatures, such as "I swear with my collateral that Alice is requesting to send XXX message from Chain A to Chain B."
  • Relayer is responsible for forwarding the message and Updater's signature to the target chain (Chain B).
  • Watcher supervises the Updater and responds if the Updater behaves maliciously.

Normal Scenario

Alice triggers the Chain A contract, requesting to send a message to Chain B
Updater signs Alice's message
Relayer forwards the message and Updater's signature to Chain B

Upon the end of the challenge period (Optimistic Window), the message takes effect, completing the cross-chain message transfer.

Updater Acts Maliciously

Updater signs a fabricated message and asks the Relayer to send it to Chain B
Watcher detects this, invalidates the message on Chain B, and submits evidence (Updater's signature) to Chain A, confiscating the Updater's collateral

The Chain A contract can clearly verify whether the message signed by the Updater is valid because the message only exists when the user directly requests it from the contract. Thus, when the Updater signs a non-existent message, this signature becomes evidence of the Updater's malicious behavior, used to confiscate the Updater's collateral.

Evidence Valid Only on Source Chain (Chain A)

The target chain (Chain B) can never know who is sending what message from Chain A, so the Chain B contract cannot confirm whether the message guaranteed by the Updater is genuine.

What can Chain B do? It needs to introduce a Permissioned Watcher. The Permissioned Watcher has the authority to invalidate any message, preventing forged messages from causing any harm. However, this role must be Permissioned, requiring trust in this role. If a Permissioned Watcher abuses their power, maliciously invalidating normal messages, then another layer of trust, such as Governance or a multi-signature Admin, would need to intervene to remove the malicious Watcher.

Assumption of at Least One Active Watcher

Unlike the security assumption in Trusted Relayers, which requires a majority of honest participants, Optimistic Verification only needs to assume that at least one Watcher is honest. This means that to breach Optimistic Verification, one would need to compromise all Watchers (e.g., through hacking, bribery, or DoS attacks).

30-Minute Challenge Period

Unlike the 7-day challenge period in Optimistic Rollup, Optimistic Verification's challenge period is only 30 minutes. This is because challenges in Optimistic Verification do not require back-and-forth interaction between the challenger and the challenged but instead involve submitting a one-time life-or-death proof: "Does the message signed by the Updater exist? (yes/no)."

3. Light client + Trustless relayers

In this type of cross-chain bridge, the target chain becomes a light node of the source chain, either by running a light node off-chain or simulating a light node on-chain through a contract: the contract records each block of the source chain and verifies the block headers. Besides verifying the content of the block headers, it also needs to verify the consensus, such as PoW validation or PoS voting results. PoW validation is relatively simple, but PoS voting results are more complex, especially with protocols like Ethereum Beacon Chain, which have over four hundred thousand validators, making it costly to maintain these lists in a contract or vote.

Additionally, each chain has different block content and consensus mechanisms, so supporting a new chain is not a straightforward task. Verification costs are higher for this type of cross-chain bridge, and the verification process is more complex compared to other bridges. However, the advantage is that it is highly secure because it does not require trust in the relayers responsible for bringing block information, as it verifies blocks and consensus autonomously.

Light Client contract verifying Chain A block information brought by the Relayer

Note: While the Relayer is just a messenger, it still requires the assumption that honest Relayers are online to ensure correct block information is relayed, preventing compromised fork chains from undermining security.

After verifying the block headers, the remaining task is to verify that a transaction exists in a block, an event is emitted in a block, or an address's storage holds a specific value. For example:

1. Verification of Alice transferring funds to an address on BTC or attaching a message in OP_RETURN

2. Verification of a Bridge contract on ETH emitting the CrossChainMessageRequested event (the event receipt is stored in the receipt tree, with the tree root recorded in the block header)

3. Verification of a Bridge contract on Optimism having a record in storage indicating Alice's cross-chain message request

Subsequently, Alice proves she initiated a cross-chain request using methods 1, 2, 3 with the Light Client contract

Upon successful verification, trust can be placed in the fact that there is indeed a cross-chain message request on the source chain.

Examples include: Cosmos IBC, Near Rainbow Bridge

Note: Cosmos IBC operates through running a light node rather than using contracts to pass messages between different (and limited to) Cosmos chains. Near Rainbow Bridge can only transfer messages between Ethereum, Near, and Aurora chains.

Aside from the complexity and high verification costs of this type of cross-chain bridge, another downside is that each chain's finality time varies. For example, BTC data may require waiting for six blocks (one hour), while ETH data may require waiting for 12.8 minutes, resulting in significantly different user experiences.

4. HTLC

HTLC stands for Hashed TimeLock Contract (the reader is assumed to understand how HTLC operates).

Note: HTLC does not necessarily have to use hash functions for commitment; it can use signatures instead.

The advantage of HTLC is its high security, but the downside is that the user experience is much poorer compared to other types of cross-chain bridges. For example: